* Ina database management system (DBMS), a deadlock occurs 


when two or more transactions are waiting for each other to 
release resources, such as locks on database objects, that they 
need to complete their operations. 


As a result, none of the transactions can proceed, leading to a 
situation where they are stuck or "deadlocked." 


* Deadlocks can happen in multi-user environments when two or 


more transactions are running concurrently and try to access the 
same data in a different order. 


* When this happens, one transaction may hold a lock on a resource 


that another transaction needs, while the second transaction may 
hold a lock on a resource that the first transaction needs. 


* Both transactions are then blocked, waiting for the other to 


release the resource they need. 


* DBMSs often use various techniques to detect and resolve 
deadlocks automatically. 


* These techniques include timeout mechanisms, where a 
transaction is forced to release its locks after a certain period of 
time, and deadlock detection algorithms, which periodically scan 
thé transaction log for deadlock cycles and then choose a 
transaction to abort to resolve the deadlock. 


* It is also possible to prevent deadlocks by careful design of 
transactions, such as always acquiring locks in the same order or 
releasing locks as soon as possible. 


* Proper design of the database schema and application can also 
help to minimize the likelihood of deadlocks 


* Ina database, a deadlock is an unwanted situation in which two or 
more transactions are waiting indefinitely for one another to give 
up locks. 


* Deadlock is said to be one of the most feared complications in 
DBMS as it brings the whole system to a Halt. 


Example 


* Suppose, Transaction T1 holds a lock on some rows in the Students 
table and needs to update some rows in the Grades table. 
Simultaneously, Transaction T2 holds locks on those very rows 
(Which T1 needs to update) in the Grades table but needs to 
update the rows in the Student table held by Transaction T1. 


* Now, the main problem arises. Transaction T1 will wait for 
transaction T2 to give up the lock, and similarly, transaction T2 will 
wait for transaction T1 to give up the lock. As a consequence, All 
activity comes to a halt and remains at a standstill forever unless 
the DBMS detects the deadlock and aborts one of the 
transactions. 
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* Mutual Exclusion: Each resource can be held by only one 
transaction at a time, and other transactions must wait for it to be 
released. 


* Hold and Wait: Transactions can request resources while holding 
on to resources already allocated to them. 


* No Preemption: Resources cannot be taken away from a 
transaction forcibly, and the transaction must release them 
voluntarily. 


* Circular Wait: Transactions are waiting for resources in a circular 
chain, where each transaction is waiting for a resource held by the 
next transaction in the chain. 


* Indefinite Blocking: Transactions are blocked indefinitely, waiting 
for resources to become available, and no transaction can 
proceed. 


* When a database is stuck in a deadlock, It is always better to 
avoid the deadlock rather than restarting or aborting the 
database. 


* The deadlock avoidance method is suitable for smaller databases 
whereas the deadlock prevention method is suitable for larger 
databases. 


* One method of avoiding deadlock is using application-consistent 
logic. 


* Inthe above-given example, Transactions that access Students 
and Grades should always access the tables in the same order. 


* In this way, in the scenario described above, Transaction T1 simply 
waits for transaction T2 to release the lock on Grades before it 
begins. When transaction T2 releases the lock, Transaction T1 can 
proceed freely. 


* When a transaction waits indefinitely to obtain a lock, The 
database management system should detect whether the 
transaction is involved in a deadlock or not. 


* Wait-for-graph is one of the methods for detecting the deadlock 
situation. This method is suitable for smaller databases. 


* In this method, a graph is drawn based on the transaction and its 
lock on the resource. If the graph created has a closed loop or a 
cycle, then there is a deadlock. 

For the above-mentioned scenario, the Wait-For graph is drawn 
below: 


Wait for Lock (R1) 


Wait for Lock (R2) 
Deadlock Situation 


* Deadlocks can be described precisely in terms o fa directed graph 
called a wait-for-graph. 


* This graph consists o fa pair G=(V, E), where V is a set of vertices 
and E is a set of edges. 


* The set of vertices consists of all transactions in the system. 
* Each element in the set E of edges is an ordered pair Ti > Tj. 


* If Ti > Tj is in E, then there is a directed edge from transaction Ti 
to Tj, implying that transaction Ti is waiting for transaction Tj to 
release a data item that it needs. 


* When transaction Ti requests a data item currently being held by 
transaction Tj, then the edge Ti Tj is inserted in the wait for 
graph. 


* A deadlock exists in the system if and only if the wait for graph 
contains a cycle. 


* Each transaction involved in the cycle is said to be deadlocked. 
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* When a detection algorithm determines that a deadlock exists, the 
system must recover from the deadlock. 


* The most common solution is to roll back one or more transactions to 
break the deadlock. 


Three actions need to be taken: 


1. Selection of a Victim: Given a set of deadlocked transactions, we 
must determine which transactions to roll back to break the 
eadlock. 


" We should roll back those transactions that will incur the minimum 
cost. 


Some other factors are: 


a. How long the transaction has computed, and how much longen the 
transaction will compute before it completes its designated task. 


b. How many data items the transaction has used. 
c. How many more data items the transaction needs for it to complete. 
d. How many transactions will be involved in the rollback. 


2. Rollback : Once we have decided that a particular transaction 
must be rolled báck, we must determine how far this transaction 
should be rolled back. 


The simplest solution is a total rollback: Abort the transaction and 
then restart it. 


However, it is more effective to rollback the transaction only as far 
as necessary to break the deadlock. Such partial rollbacks require 
the system to maintain additional information about the state of all 
the running transactions. 


3: Starvation: In a system where the selection of victims is based 
primarily on cost factors, it may happen that the same transaction 
is always picked as a victim. 


* Asaresult, this transaction never completes its designated task, 
thus there is starvation. 


* We must ensure that a transaction can be picked as a victim only a 
finite number of times. 


* The most common solution is to include the number of rollbacks in 
the cost factor. 


* Fora large database, the deadlock prevention method is suitable. 
A deadlock can be prevented if the resources are allocated in such 
a way that a deadlock never occurs. 


* The DBMS analyzes the operations whether they can create a 
deadlock situation or not, If they do, that transaction is never 
allowed to be executed. Deadlock prevention mechanism 
proposes two schemes: Wait Die Scheme, Wound wait Scheme 


* In this scheme, If a transaction requests a resource that is locked 
by another transaction, then the DBMS simply checks the 
timestamp of both transactions and allows the older transaction 
to wait until the resource is available for execution. 

Suppose, there are two transactions T1 and T2, and Let the 
timestamp of any transaction T be TS (T). Now, If there is a lock on 
T2 by some other transaction and T1 is requesting resources held 
by T2, then DBMS performs the following actions: Checks if TS 
(Ta) < TS (T2) - if T1 is the older transaction and T2 has held some 
resource, then it allows T1 to wait until resource is available for 
execution. 


That means if a younger transaction has locked some resource and 
an older transaction is waiting for it, then an older transaction is 
allowed to wait for it till it is available. 


If T1 is an older transaction and has held some resource with it and 
if T2 is waiting for it, then T2 is killed and restarted later with 
random delay but with the same timestamp. i.e. if the older 
transaction has held some resource and the younger transaction 
waits for tHe resource, then the younger transaction is killed and 
restarted with a very minute delay with the same timestamp. 


* This scheme allows the older transaction to wait but kills the 
younger one. 


* In this scheme, if an older transaction requests for a resource held 
by a younger transaction, then an older transaction forces a 
younger transaction to kill the transaction and release the 


resource. 
* The younger transaction is restarted with a minute delay but with 
the same timestamp. 


* Ifthe younger transaction is requesting a resource that is held by 
an older one, then the younger transaction is asked to wait till the 


older one releases it. 


* Delayed Transactions: Deadlocks can cause transactions to be 
delayed, as the resources they need are being held by other 
transactions. This can lead to slower response times and longer wait 
times for users. 


* Lost Transactions: In some cases, deadlocks can cause transactions to 
be lost or aborted, which can result in data inconsistencies or other 
issues. 


* Reduced Concurrency: Deadlocks can reduce the level of concurrency 
in the system, as transactions are blocked waiting for resources to 
become available. This can lead to slower transaction processing and 
reduced overall throughput. 


* Increased Resource Usage: Deadlocks can result in increased resource 
usage, as transactions that are blocked waiting for resources to 
become available continue to consume system resources. This can lead 
to performance degradation and increased resource contention. 


* Reduced User Satisfaction: Deadlocks can lead to a perception of poor 
system performance and can reduce user satisfaction with the 
application. This can have a negative impact on user adoption and 
retention. 


* Database recovery techniques are used in database management 
systems (DBMS) to restore a database to a consistent state after a 
failure or error has occurred. The main goal of recovery techniques is 
to ensure data egy and consistency and prevent data loss. There 
are mainly two types of recovery techniques used in DBMS: 


* Rollback/Undo Recovery Technique: The rollback/undo recovery 
technique is based on the principle of backing out or undoing the 
effects of a transaction that has not completed successfully due to a 

ffects of at ction that has not completed su fully due t 
system failure or error. This technique is accomplished by undoing the 
changes made by the transaction using the log records stored in 
transaction log. he transaction log contains à record of all the 
transactions that have been performed on the database. The system 
uses the log records to undo the changes made by the failed 
transaction and restore the database to its previous state. 


Commit/Redo Racovary Tac ques The commit/redo recovery 
technique is based on the principle of reapplying the changes made by 
a transaction that has been completed successfully to the database. 
This technique is accomplished by using the log records stored in the 
transaction log to redo the changes made by the transaction that was 
in progress at the time of the failure or error. The system uses the log 
records to reapply the changes made by the transaction and restore 
the database to its most recent consistent state. 


* The techniques used to recover the lost data due to system 
crashes, transaction errors, viruses, catastrophic failure, incorrect 
commands execution, etc. are database rdzovery techniques. 


* Soto prevent data loss recovery techniques based on deferred 
update and immediate update or backing up data can be used. 


* Recovery techniques are heavily dependent upon the existence of 
a special file known as a system log. 


* It contains information about the start and end of each transaction 
and any updates which occur during the transaction. 


* The log keeps track of all transaction operations that affect the 
values of database items. 


* This information is needed to recover from transaction failure. 


la : 
* The log is kept on disk start_transaction(T): This log entry records that 
transactionT starts the execution. 


read_item(T, X): This log entry records that transaction T reads the 
value of database item X. 


write_item(T, X, old_value, new_value): This log entry records that 
transaction T changes the value of the database item X from old, value 
to new. value. The old value is sometimes known as a before an image 
of X, and the new value is known as an afterimage of X. 


commit(T): This log entry records that transaction T has completed all 
accesses to the database successfully and its effect can be committed 
(recorded permanently) to the database. 


abort(T): This records that transaction T has been aborted. 


checkpoint: Checkpoint is a mechanism where all the previous logs are 
removed from the system and stored permanently in a storage disk. 


Checkpoint declares a point before which the DBMS was in a consistent 
state, and all the transactions were committed. 


* This technique does not physically update the database on disk 
until a transaction has reached its commit point. 


* Before reaching commit, all transaction updates are recorded in 
the local transaction workspace. 


* If a transaction fails before reaching its commit point, it will not 
have changed the database in any way so UNDO is not needed. 


* It may be necessary to REDO the effect of the operations that are 
recorded in the local transaction workspace, because their effect 
may not yet have been written in the database. 


* Hence, a deferred update is also known as the No-undo/redo 
algorithm 


* Inthe immediate update, the database may be updated by some 
operations of a transaction before the transaction reaches its 
commit point. 


* However, these operations are recorded in a log on disk before 
they are applied to the database, making recovery still possible. 


+ Ifa transaction fails to reach its commit point, the effect of its 
operation must be undone i.e. the transaction must be rolled back 
hence we require both undo and redo. 


* This technique is known as undo/redo algorithm. 


* Shadow Paging is recovery technique that is used to recover database. 


* In this recovery technique, database is considered as made up of fixed 
size of logical units of storage which are referred as pages. 


* Pages are mapped into physical blocks of storage, with help of the page 
table which allow one entry for each logical page of database. 


* This method uses two page tables named current page 
table and shadow page table. 


* The entries which are present in current page table are used to point to 
most recent database pages on disk. 


* Another table i.e., Shadow page table is used when the transaction starts 
which is copying current page table. 


* After this, shadow page table gets saved on disk and current page table is 
going to be used for transaction. 


* Entries present in current page table may be changed during execution 
but in shadow page table it never get changed. 


* After transaction, both tables become identical. This technique is also 
known as Cut-of-Place updating. 
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* To understand concept, consider above figure, In this 2 write 
operations are performed on page 3 and 5. Before start of write 
operation on page 3, current page table points to old page 3. When 
write operation starts following steps are performed : 


* Firstly, search start for available free block in disk blocks. 


* After finding free block, it copies page 3 to free block which is 
represented by Page 3 (New). 


* Now current page table points to Page 3 (New) on disk but shadow 
page table points to old page 3 because it is not modified. 


* The changes are now propagated to Page 3 (New) which is pointed 
by current page table. 


* COMMIT Operation : To commit transaction following steps 
should be done: 


* All the modifications which are done by transaction which are 
present in buffers are transferred to physical database. 


* Output current page table to disk. 


* Disk address of current page table output to fixed location which is 
in stable storage containing address of shadow page table. 


* This operation overwrites address of old shadow page table. 


* With this current page table becomes same as shadow page table 
and transaction is committed. 


* Failure : If system crashes during execution of transaction but 
before commit operation, With this, it is sufficient only to free 
modified database pages and discard current page table. 


* Before execution of transaction, state of database get recovered 
by reinstalling shadow page table. ^ 


* If the crash of system occur after last write operation then it does 
not affect propagation of changes that are made by transaction. 


* These changes are preserved and there is no need to perform redo 
operation. 


* This method require fewer disk accesses to perform operation. 

* Inthis method, recovery from crash is inexpensive and quite fast. 
* There is no need of operations like- Undo and Read. 

* Recovery using this method will be faster. 


* Improved fault tolerance: Shadow paging provides improved 
fault tolerance since it isolates transactions from each other. This 
means that if one transaction fails, it does not affect the other 
transactions that are currently executing. 


* Increased concurrency: Since modifications made during a 
transaction are written to the shadow copy instead of the actual 
database, multiple transactions can be executed concurrently 
without interfering with each other. This leads to increased 
concurrency and better performance. 


* Due to location chan: 


* During commit operation, changed blocks are 


g on disk due to update database it is quite difficult to keep 
related pages in database closer on disk. 

going to be pointed by shadow 
age table which have to be returned to collection of free blocks otherwise they 
ecome accessible. 


* The commit of single transaction requires multiple blocks which decreases 


* Garbage collection: Garbage will accumulate in the pa 


execution speed. 
To allow this technique to multiple transactions concurrently it is difficult. 


Data frngmentstonithe main disadvantage of this technique is the updated 
Data will suffer from fragmentation as the data is divided up into pages that may 
or not be in linear order for large sets of related hence, complex storage 


management strategies. 
ges on the disk as data is 


updated and pages lose any references. For example if i have a page that 
contains a data item X that is replaced with a new value then a new page will be 
created. Once the shadow page table is updated nothing will reference the old 
value of X. The operation to migrate between current and shadow directories 


must be implemented as an atomic mode. 


Performance overhead: Since modifications made during a transaction are 
written to the shadow copy, there is a performance overhead associated with 
copying the changes back to the actual database once the transaction is 
committed. This can impact the overall performance of the system. 


